The asynchronous transfer of messages between application programs running in different data processing systems within a network is well known in the art, and is implemented by a number of commercially available messaging systems. These systems include IBM Corporation's WebSphere MQ family of messaging products, which use asynchronous messaging via queues. A sender application program issues a put message command to send a message to a target queue, and a WebSphere MQ queue manager program handles the complexities of transferring the message from the sender to the target queue, which may be remotely located across a heterogeneous computer network. The target queue is a local input queue for another application program, which retrieves the message from this input queue by issuing a get message command asynchronously from the send operation. The receiver application program then performs its processing on the message, and may generate further messages.(IBM, WebSphere and MQ are trademarks of International Business Machines Corporation in the United States, other countries, or both.)
Messaging can be persistent or non-persistent. In non-persistent messaging there is no assurance that the message will be delivered. In persistent messaging there is an assurance of delivery and, in one technique, this is achieved by storing the message (often referred to as “hardening”) to non-volatile memory (e.g. a disk storage device) as part of the messaging process. This means that if the messaging system fails during the message transfer then the message can be recovered. Although persistent messaging prevents loss of messages, there is a significant overhead involved in hardening to disk.
Messaging can be transactional or non-transactional. Transaction processing is a well known technique and in general terms involves the execution of discrete units of work that access and update shared data. Logical points of consistency at which resource changes are synchronized within transaction execution are called commit points or syncpoints. An application ends a unit of work by declaring a syncpoint or by the application terminating. The characteristic of a transaction being accomplished as a whole or not at all is known as ‘atomicity’. Atomicity of a transaction is known to be achieved by resource updates made within the transaction being held uncommitted until a syncpoint is declared at completion of the transaction. That is, the resource updates are only made permanent and visible to applications other than the one which performed the updates on successful completion. If the transaction fails to complete successfully, then all changes that have been made to resources during the partial execution are removed. The transaction is said to rollback (or backout) and the resources are restored to the consistent state which existed before the transaction began. Any party (e.g. an application or resource manager) with an interest in the unit of work can cause a rollback when a syncpoint is declared by indicating unreadiness to commit.
In one example of transactional processing as applied to persistent messaging, a message is put inside a syncpoint and, when committed, is hardened to disk. A number of messages may advantageously be batched inside a single syncpoint and hardened to disk as a batch thus improving the efficiency of the operation.
A particular form of messaging is the publish/subscribe architecture where a publisher application may put a message to a plurality of subscriber applications. The model enables the publisher and subscriber to be independent and unaware of the nature of each other.
A problem encountered in transactional messaging of persistent messages is the performance overhead of hardening transactions to disk. In some circumstances in high integrity transactional systems, the input/output overhead can degrade the performance of the system.
In non-transactional messaging, it is known to reduce hardening to disk of a persistent message by avoiding queuing.
An aim of the present invention is to provide a method that allows a set of interacting transactions to commit efficiently by trading off transaction independence (failure isolation and serialization) against performance.
In an environment where a producer and consumer are both available, then using inherited transactions communication is synchronous. If the consumer is unavailable then communication is asynchronous. In both cases the producer and consumer are largely unaware of the existence of the synchronous path (i.e. the asynchronous programming model is followed). Inherited transactions can reduce the input/output overhead in a highly serialized messaging environment.
In the field of distributed messaging, the coordination of transactions by external syncpoint managers use an industry-standard XA interface defined by an X/Open Group CAE Specification—Distributed Transaction Processing. An XA syncpoint coordinator can manage a set of XA resource managers and synchronise commit or backout of transactions in both resource managers.
The XA interface includes XA suspend/resume protocols, and at an XA level the problem of the number of forced inputs/outputs might be addressed by suspending and resuming the transaction.
However, there are a number of reasons why the XA capabilities are not used to resolve the problem, including the following:    1. Although the number of forced inputs/outputs is reduced there is still a considerable overhead in putting the publish request on the stream queue and then getting it off again.    2. The transaction isolation model would not give the correct message visibility. All activity would occur in a single transaction and it would not be possible to distinguish between a message being passed from the producer to the consumer and a message being passed in the other direction.    3. The internal overheads in XA transaction management are considerable.
With the inherited transactions, there is no loss of transactional integrity. Either all of the activities associated with the producer's message will complete or none of them will complete. However, there is a potential loss of independence between the participating components. For example, if a subscriber decides to backout the transaction, then it isn't always clear whether the publisher is made aware of this fact.
A key feature of asynchronous messaging is that, by its nature, it decouples the operations of the participating components to provide transaction independence. This provides independence between message producers and consumers. If the operations are nested in a single inherited transaction, there is a risk that this transaction independence may be lost.
If the activities in an inherited transaction are completely serial, then it is trivial for the queue manager to intercept a negative vote for commit and take appropriate compensating action thus hiding this activity from the other participants and continuing to provide a reasonably high degree of transparency of the inherited transaction capability. However, a strictly serial execution has performance costs.
A further aim of the present invention is to provide inherited transactions in persistent asynchronous messaging while maintaining participating application isolation. Performance is balanced with independence of the participants by optionally allowing the participants of the transaction to execute in parallel.